前文链接：是时候使用SaveState了
要使前文介绍的5.0新机制生效，应用需要设计为多Task结构，而且要处理好页面的SaveState相关逻辑。
这里先讨论SaveState的相关逻辑，再介绍怎么设计应用的Task结构。
处理SaveState的四个方面
在之前演示代码的基础上，我们稍做改动：代码链接
- ActivityTwo包含一个文字列表
- 文字列表中每一项的前缀是由启动的Intent的Extra决定
- 文字列表中每一项的后缀是由创建页面的时间戳决定
如果我们不处理SaveState，则在恢复ActivityTwo时，列表中每一项的后缀会发生变化，如果处理SaveState，则能保证返回时页面和创建时一样。在代码中通过修改ActivityTwo#ENABLE_SAVE_STATE可以切换两种状态。
创建时的页面：
不处理SaveState恢复后的页面
处理SaveState恢复后的页面
SaveState的处理应该包括4个部分
- 保存数据
- 恢复数据
- 处理View
- 处理Fragment
第一：保存数据
这一步相对简单，只要把页面中的数据变量保存到outState中
@Override
protected void onSaveInstanceState(Bundle outState) {
super.onSaveInstanceState(outState);
if (ENABLE_SAVE_STATE) {
outState.putString(KEY_PREFIX, mPrefix);
outState.putString(KEY_SUFFIX, mSuffix);
}
}
实际项目中，可能由Intent中传入页面id，再通过网络接口获取页面详情。这时，也需要将网络返回的数据也保存在outState中。
第二：恢复数据
恢复数据时，需要考虑onCreate的正常处理逻辑
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_two);
mListView = (ListView) findViewById(R.id.lv);
if (ENABLE_SAVE_STATE && savedInstanceState != null) {
// 恢复流程
mPrefix = savedInstanceState.getString(KEY_PREFIX);
mSuffix = savedInstanceState.getString(KEY_SUFFIX);
mListView.setAdapter(new TwoAdapter(mPrefix, mSuffix));
} else {
// 初始化流程
mPrefix = getIntent().getStringExtra(KEY_PREFIX);
mSuffix = String.valueOf(SystemClock.uptimeMillis());
mListView.setAdapter(new TwoAdapter(mPrefix, mSuffix));
}
}
实际项目中，初始化网络请求应放初始化流程中，而类似mListView.setAdapter的View更新逻辑应该在网络请求的回调中处理。
第三：处理View
上面的例子中，除了ListView的内容，我们还应注意到ListView的位置。不管我们是否处理SaveState，ListView都会恢复到离开时的位置。这是因为ListView的基类AbsListView实现了Save和Restore，下面是节选的一小段源码。
// AbsListView
@Override
public Parcelable onSaveInstanceState() {
......
Parcelable superState = super.onSaveInstanceState();
SavedState ss = new SavedState(superState);
if (mPendingSync != null) {
// Just keep what we last restored.
ss.selectedId = mPendingSync.selectedId;
ss.firstId = mPendingSync.firstId;
ss.viewTop = mPendingSync.viewTop;
ss.position = mPendingSync.position;
ss.height = mPendingSync.height;
ss.filter = mPendingSync.filter;
ss.inActionMode = mPendingSync.inActionMode;
ss.checkedItemCount = mPendingSync.checkedItemCount;
ss.checkState = mPendingSync.checkState;
ss.checkIdState = mPendingSync.checkIdState;
return ss;
}
.......
}
除了AbsListView，还有很多View实现了Save和Restore的机制，包括ViewPager当前的位置，EditText和TextView中的文本等。
关于View的处理主要注意以下几点：
- 系统以一个Map来保存View的状态，以id为key
- 没有id的View是不会被保存状态的
- 如果id重复，则View的状态会被覆盖
- 自定义的View，要注意处理View的Save和Restore
- 如果View的恢复有特殊处理逻辑，需要充分考虑View更新的时机，注意onCreate、onRestoreInstanceState和网络请求回调的时序问题。
第三：处理Fragment
关于Fragment的处理，和Activity的处理基本一致。只需要注意一个特殊的地方
很多项目都会只在Manifest中声明一个FragmentContainerActivity的模式，各个页面通过Fragment实现。然后启动FragmentContainerActivity，通过Extra传递要展现的Fragment类名和Argument。FragmentContainerActivity#onCreate中创建并添加Fragment。
由于Activity的恢复机制会自动重建Fragment，所以在恢复时不要再重复创建添加Fragment。当然也不要新创建，并通过replace替换老的，这样会使Fragment的恢复机制失效。
这部的例子演示，可使用如下步骤复现：
- 修改
ActivityThree#ENABLE_SAVE_STATE进行切换 - 启动Three
- 点击Three的文字可返回到One
- 在One中消耗内存，直到logcat中出现
ActivityThree#onDestroy - 再次启动Three
合理区分Task
Android关于Task的定义十分复杂，而且很多特性在普通应用开发中根本用不到。而且在5.0之后，又引入了android:documentLaunchMode让它变得更加复杂了。
关于Task，还需要另一篇专题来讨论。这里只举两类多Task的例子。
使用singleInstance
给一些特定的页面设置singleInstance，可使他们处于单独的Task中。这类页面一般和其他页面没有很强的逻辑关系，同时又是消耗资源的大户。
适用场景：
- 视频播放或录制页（视频的编码解码，视频上的绚丽弹幕和礼物等）
- 应用介绍页（包含很多大图和动画）
- 应用内用于现实外部网页的单WebView页
- ViewPager实现的大图图集页
使用taskAffinity
给一组完成某一功能的Activity设置相同的taskAffinity，就可使用FLAG_ACTIVITY_NEW_TASK启动新Task。使用taskAffinity启动的新Task一般都包括多个Activity，而且和别的参数相互影响，请谨慎使用。
适用场景：
- 注册、登陆、找回密码等页面（这类页面一般占用的资源并不多，不一定要设计在独立的Task中）
- 自定义的选择相册，照相机，图片预览，图片裁剪等页面
关于多Task的补充
由于不同的Task之间不能通过StartActivityForResult传递结果，可能需要EventBus或其他机制在Task之间传递信息。
默认的每个Task都会出现在最近应用中。上述的这些情况中，都可使用android:excludeFromRecents避免这些Task在最近应用中出现
后面单独补充了一节进程被杀的介绍，因为它很容易和Task中Activity销毁混淆
Task中Activity销毁 vs 进程被杀
我们先看下再ActivityManagerService中进程Process和Task的关系
-
ActivityManagerService通过一个列表mHistory来管理所有ActivityRecord - 相同
TaskRecord中的ActivityRecord在列表中处于连续位置 - 同一个
TaskRecord中的ActivityRecord可能处于不同的ProcessRecord中
由于以下两个因素，使得很难找到Task和进程之间关联的清晰线索。
- 同一Task中的Activity可能属于不同进程
- 进程中不仅有Activity，还有Service和BroadcastReceiver
先看Task中Activity销毁
- 处理的问题：一个进程内部，前后台Task的资源协调
- 触发时机：进程使用的内存接近上限时（根据机型不同，大约在64M～256M之间）
再看进程被杀
- 处理的问题：系统控制中，多进程之间的资源协调
- 触发时机：整个系统使用的内存接近机器配置的内存上限时
我们以一个简化的例子讨论两者的关系。假设：
- 单进程最大可使用内存为100M，进程使用内存超过90M时会触发后台Task销毁。
- 系统总可用内存为200M，系统使用内存超过190M时会触发后台进程被杀。
- 系统中运行着3个进程，他们在三个Task中的分布和内存使用如下
- Task1处于前台运行
| Momory Usage | Process1 | Process2 | Process 3 |
|---|---|---|---|
| Task1 | 60M | 20M | - |
| Task2 | 20M | 20M | - |
| Task3 | - | - | 40M |
如果T1 P1部分消耗的内存由60M上升到75M，由于P1的总内存消耗达到95M，所以会导致P1 T2中的Activity被销毁。
如果T1 P2部分消耗的内存由20M上升到50M，会导致系统总内存消耗达到190M。此时三个Process中，P1和P2和前台Task关联，优先级较高，所以系统会杀掉P3。
这个例子，只是对两者关系的一个简要说明。系统对进程的实际处理方式要复杂得多！
- 原文链接
- 我的主页：www.huangyifei.info
- 微信订阅号：tech_galaxy
